Before we can have a “sense and respond” network, we have to have sensors to prompt a response. For the demonstration, we’ll add a photo cell to the protoboard and use a script to monitor it.
This example uses a protoboard setup from the exercise Interacting with a Node via Portal Before performing this exercise, you'll need to connect LEDs to the SN171 protoboard in the same fashion.
Historical Note: That phrase was coined in 1911. When adjusted for inflation, a picture is now worth about 41 words. We expect that cell phones have flooded the photo market. Still, pictures are pretty handy.
The “HolidayLightShow” script is already monitoring for changes in light levels on the SN171 protoboard. (Sneaky, we know.) However, the script includes an “auto-calibration” capability and, since we have not “calibrated” the sensor yet, no values will be acted upon.
NOTE: Sometimes holding your finger close to the sensor will trigger it twice. If the LEDs behave erratically, move your hand away and then close again to trigger the transition again. Remember, a sense and respond network is only as good as the sensors.
Success! We now have a device that will sense when the sun goes down and begin a Christmas light show one night and a Halloween light show the next.
When the node boots it begins monitoring light levels. As soon as the sensor calibrates, the node's script sends a multicast message each time light levels drop below the defined threshold, and it instructs all nodes to change the light show by invoking the christmasBlink() or halloweenBlink() function.
The RF220 node on the SN171 protoboard is running the HolidayLightShow script, which defines christmasBlink() and halloweenBlink() as commands to GPIO connected LEDs. The SN132 SNAPstick is running the HolidayBlink script which defines them both as commands to the LEDs on the SNAPstick.
In this way, a number of different devices can respond to the same command in unique ways that are each suited to their application. This was a simple example, but broader applications can get quite complex.
The hazard of RPCs is, the receiving node determines what happens from the call.
The same call to these three nodes produces very different sandwiches. A fourth node with no such function defined would totally ignore the message.